fix(tlsn): raise mux max_num_streams to 2048 - #1159
Open
heeckhau wants to merge 1 commit into
Open
Conversation
MPC preprocessing opens roughly ~24 streams per TLS record. The mux
default limit of 512 concurrent streams was exceeded by realistic
transcript sizes, causing preprocessing to fail with `TooManyStreams`:
ERROR tlsn_mux::connection::active: maximum number of streams reached
ERROR mpc_tls::follower: error=preprocess error: ... context mux error
Measured peaks (instrumenting the mux at the pinned rev):
- max_sent=4096, max_recv=16384 -> 285 streams
- max_sent=8192, max_recv=70000 -> 555 streams (the production failure)
Raise the limit to 2048 (~3.7x the measured peak). This stays within the
default 1 GiB connection receive window (which must be >= 256 KiB *
max_num_streams), preserving a 512 MiB stream-window auto-tuning pool, so
throughput is not affected.
Adds a regression test that opens 1024 concurrent streams through a
session's mux, which fails at the old 512 default.
Member
|
The issue is that the number of streams increases proportional to work, so this is not a robust fix. Updating TLSNotary to use this change on mpz should address it: ethereum/mpz#403 |
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
MPC preprocessing fails with
TooManyStreamson realistic transcript sizes:The mux's default limit is 512 concurrent streams. The threading design opens many more during preprocessing — roughly ~24 streams per TLS record — so a moderately-sized transcript tips it over. The existing integration tests use a smaller config and never reached the limit, so this wasn't caught.
Measurement
Instrumented the pinned mux rev to record peak concurrent streams during the real end-to-end MPC flow:
max_sentmax_recvThe peak scales with transcript size; 512 sat right in the middle of the realistic range.
Fix
Raise
max_num_streamsto 2048 (~3.7× the measured peak).This deliberately stays below 4096: the mux requires
max_connection_receive_window >= 256 KiB * max_num_streams, and the default window is 1 GiB. At 2048 the reserved minimum is 512 MiB, leaving a 512 MiB auto-tuning pool so per-stream receive windows can still grow — whereas 4096 would consume the entire window and pin every stream to 256 KiB, hurting throughput. Memory is allocated lazily per opened stream, so the higher ceiling itself costs nothing.Test
Adds
test_session_allows_many_concurrent_streams, which opens 1024 concurrent streams through a session's mux. It fails at the old 512 default and passes with this change.Follow-up
The peak scales with transcript size. If deployments support substantially larger transcripts than
max_recv=70000, bothmax_num_streamsandmax_connection_receive_windowshould be raised together (keeping thewindow >= 256 KiB * max_num_streamsinvariant) rather than bumping the stream cap alone.